SSR Flavors

Using my course platform as an example, we saw an example of how Server Side Rendering can be implemented:

1. User visits a lesson page.
2. The server receives the request, and does the first React render, generating the initial HTML.
3. User receives a fully-formed HTML document, so they can start learning even while the JavaScript bundles are downloading.

This is known as on demand server side rendering. The HTML is generated “just-in-time”, when the server receives the request.

It's not the only strategy we can use, though! SSR comes in many different flavors. Another popular implementation is called Static Site Generation, SSG.

This is the strategy I use on my blog, joshwcomeau.com (opens in new tab).

The big innovation with SSG is that the HTML is generated ahead of time. Instead of rendering our React application on demand (when a request is received), we do the render at compile-time.

We've talked a little bit about how React apps need to be compiled. This process does a bunch of stuff:

• Turns JSX into browser-friendly JavaScript.
• Runs any checks, like ESLint.
• Bundles all of our individual JavaScript files into a handful of scripts.

With SSG, we add one more step to this pipeline: Generate the initial HTML for each page by doing the first React render.

We then upload all of the HTML files to our server, and those files are served “as-is” when the user requests them.

Think about what this means from a performance perspective. When a user visits joshwcomeau.com/animation/css-transitions/, the server immediately sends along the fully-formed HTML document. The server doesn't have to do any processing at all, because that work was already done during the compile step!

Let's clear up something that often gets confused in online discussions about this stuff.

The term “Server Side Rendering” refers very specifically to one thing: Using the react-dom/server APIs to generate the HTML in Node.js:

import { renderToString } from 'react-dom/server';

import App from './components/App';

const html = renderToString(<App />);

No matter whether we run this code on-demand, like we saw with my course platform, or at compile-time, like I do with my blog, they both fit under the “Server Side Rendering” umbrella, because they both use the same APIs. The only difference between them is the timing!

With SSG, we call the renderToString method when we compile our site, and save the HTML files to disk, to be served to users when they visit the page. With “on-demand” SSR, we call renderToString in response to a user request, to generate the HTML right as it's needed. Ultimately, these are two different “flavors” of SSR.

A third flavor, created by Next.js, is called Incremental Static Regeneration (ISR)

*

.

The ISR flow is a bit hard to explain in words, so here's an interaction that should (hopefully) make it clear. Try clicking "Request page" for a couple of the people here:

Noora

Request page

vladimir

Request page

Ned

Request page

Server

Discard Generated File

The first time a user requests a particular page, the server will generate the HTML and send it to the user, the same as “on-demand” server-side rendering. The difference is that it hangs onto that generated HTML. The next time someone requests that same page, Next will automatically serve up that pre-generated HTML, same as SSG.

In order to prevent the generated file from growing too stale, we can configure Next to regenerate the HTML file after a certain amount of time has passed. This is known as revalidation.

For example, suppose we set a revalidation time of 60 minutes. When someone visits this page after 61 minutes, the Next server will serve that user the stale HTML file, but will start a brand new Server Side Render in the background. The next user will get the fresh, newly-generated file.

You can learn all about Incremental Static Regeneration in the Next docs (opens in new tab), though honestly I don't think it's something you need to dig into right now.

Here's the important takeaway: “Server Side Rendering” is an umbrella term that can refer to many different potential strategies! They each have their own pros and cons, but fundamentally, they all serve the same purpose: to improve performance.

So, here's a question: why doesn't my course platform use Static Site Generation?

With on-demand SSR, the server has to spend some time generating the HTML, whereas with SSG, the HTML file already exists. And so, wouldn't it be better to use SSG on my course platform?

Put another way: Can you think of any drawbacks to SSG?

Spend a few moments thinking about it, and see if you can come up with 2 or 3 possible reasons. You can use this text box as a notepad, to store your thoughts:

Once you've thought about it for a little while, expand to see my answer: